SOC 2 Type I
for AWS-Native Teams

These decisions determine how much work the next few months are. Get them wrong and you'll overbuild. Most teams skip this and regret it.

• Confirm you actually need a SOC 2, not just a vendor questionnaire

  Ask your buyer directly: "Would a detailed security documentation package satisfy your requirements?" Many say yes. SOC 2 is 2–4 months and $10K+. Make sure it's required before you start.
• Confirm Security is your only Trust Services Criterion

  Add Availability only if you have contractual uptime SLAs. Add Privacy only if you process EU or health data. Every additional criterion adds scope, controls, evidence, and auditor time. Default to Security only.

  Why the auditor cares: scope defines the entire engagement. Ambiguity here adds weeks and fees on both sides.
• Define your system boundary

  Your "system" is the product your customer uses, not your whole company. Typically: compute (EC2/ECS/Lambda), databases (RDS/DynamoDB), customer-data storage (S3), and CI/CD pipeline. Notion, Figma, and Slack are out. Narrow the boundary. Every in-scope system needs controls and evidence.

  Why the auditor cares: they write their opinion against the system boundary you define. A vague boundary means mid-engagement questions you'll have to answer on their clock.
• Assign a named owner to every control

  Before you collect a single piece of evidence, decide who owns each control. Your auditor will ask "who is responsible for this?" and "the team" is not an answer. For a 5-person company, one person can own multiple controls. Just make it explicit.

  Why the auditor cares: CC1.2 requires demonstrated assignment of responsibility. An unowned control looks like no one is accountable for it.
• Get actual buy-in from whoever writes the check

  Type I takes 2–4 months, 1–2 engineers part-time, and $8–15K. Someone needs to say "yes, we're doing this" before you start building infrastructure for it.

SOC 2 isn't just about having policies. Your infrastructure has to actually match what your policies say. For AWS teams, this is both the biggest risk and the most automatable part of the process.

• Run a gap assessment before you do anything else

  Manually using the table above, or via a scanner. The output is a list of what's currently failing. Finding gaps yourself costs nothing. Finding them during an audit costs auditor time at $300/hour.

  Why the auditor cares: they will find everything in that table. The question is whether you find it first.
• Enable MFA on all IAM users and root. No exceptions.

  The most common finding in AWS audits. One IAM user without MFA is a flag. Takes 10 minutes to fix. A single stolen password without MFA means full account access.

  Why the auditor cares: root without MFA is a design failure in your access model. CC6.1. It will be noted prominently.
• Rotate or delete stale access keys per your Access Control Policy

  There is no SOC 2 "90-day rule" for key rotation. The auditor checks against whatever your own Access Control Policy says. AWS best practice recommends 90 days. Many auditors accept 180. Pick a cadence, write it in your policy, then actually follow it. Pull your IAM credential report now and check.

  Why the auditor cares: a policy you're not following is evidence of negligence, not compliance.
• Enable CloudTrail in all regions with log file validation on

  CloudTrail is your audit log. Every API call in your AWS account. Multi-region and log file validation (proves nobody tampered with the logs) are both required. Without CloudTrail, your auditor literally cannot verify change management or incident response.

  Why the auditor cares: CC7.2. No CloudTrail means no trail. The audit cannot proceed against controls that require it.
• Enable GuardDuty in every region you use

  2 minutes to enable. If you already have it on but have been ignoring the findings, that is the more important conversation to have before your auditor has it for you.

  Why the auditor cares: GuardDuty off means no threat detection. CC7.3. It also signals security ops aren't a priority, which colors how they read everything else.
• Lock down every S3 bucket: encryption on, public access blocked, versioning on critical buckets

  Run GetPublicAccessBlock on every bucket. A publicly accessible bucket with customer data is an immediate critical finding. Lock it before your audit starts.

  Why the auditor cares: a public S3 bucket with customer data means you may have already had a breach you don't know about. This stops the audit.
• Review VPC security groups for open inbound rules

  0.0.0.0/0 on port 22 (SSH) or 3389 (RDP) gets flagged immediately. Restrict to specific IP ranges or use a bastion host.

  Why the auditor cares: an open SSH port is an open invitation. CC6.6 requires controlled network boundaries. A wide-open security group means you don't have one.

SOC 2 requires written policies for basically everything. They don't need to be long. They need to be real — meaning your team follows them and your infrastructure actually matches them.

• Information Security Policy

  The master document. Who is responsible for security, what you're protecting, and how. Every other policy links back to this one. 2–3 pages is fine.

  Why the auditor cares: CC1.4 requires demonstrated management commitment to security. This is that commitment in writing.
• Access Control Policy

  Who gets access to what, how you provision and deprovision users, MFA requirements, least-privilege. For AWS-native teams, this mostly describes what your IAM setup already does. If your IAM is clean, writing this is 30 minutes.

  Why the auditor cares: CC6.1 and CC6.2. Without this policy, there's no standard to measure your IAM config against.
• Incident Response Plan

  Who gets called, in what order, what gets documented. Walk through it out loud with your team once. If you can't execute it under stress at 2am, it won't pass.

  Why the auditor cares: CC7.4. Without a plan, a breach becomes a disaster. They want evidence you've thought about this before it happens.
• Change Management Policy

  How code goes from a developer's laptop to production. If you're already on GitHub with required PR reviews, write that down. That is your policy.

  Why the auditor cares: CC8.1. Undocumented change processes mean anything could have shipped without a record. They need to trace changes back to approvals.
• Risk Assessment

  Annual exercise: what could go wrong, how likely, what are you doing about it. A 2-page Google Doc works. This is foundational — it's the process that justifies all your other controls. Without it, your controls look arbitrary.

  Why the auditor cares: CC3. Auditors who find no documented risk process treat every other control as unanchored.
• Vendor Management Policy

  A list of your critical vendors (AWS, Stripe, Anthropic, GitHub, etc.), confirmation they're SOC 2 compliant, and how you evaluate new vendors. For most lean teams: a spreadsheet with their compliance pages bookmarked.

  Why the auditor cares: CC9.2. Your vendors are part of your attack surface. They need to see you've thought about it.
• Business Continuity / Disaster Recovery Plan

  What happens if production goes down. RDS backup schedules, recovery time objectives, who calls who. If you have automated RDS snapshots, document them. That's your database DR plan.

  Why the auditor cares: A1.2 and A1.3. Without a documented DR plan, there's no guarantee you could recover customer data after an incident.
• Security training records and background checks

  Training: a 30-minute read of your security policies with a signed acknowledgment per employee. The signature matters more than the length. Background checks: document your process for employees with access to customer data. Auditors ask about both.

  Why the auditor cares: CC1.4. Untrained employees with no background screening are a risk to customer data, not just your audit.

For Type I, you need point-in-time evidence proving your controls are real as of the audit date. This step takes the most calendar time. Budget 40–60 hours if you're doing it manually.

• Organize evidence by control, not by AWS service

  Your auditor thinks in criteria (CC6.1, CC7.2), not services (IAM, CloudTrail). A folder called "CC6.1-access-controls" with your IAM report, MFA status, and password policy is what they want. A folder called "AWS screenshots" is not.
• Every piece of evidence needs a timestamp and a source

  A screenshot with no date is not evidence. An API response with a timestamp and the exact call that produced it is. Auditors increasingly want API-native evidence over screenshots. It's tamper-evident and traceable.
• Pull your IAM credential report and review it before the auditor does

  One report shows who has access, last login time, MFA status, and access key age. Your auditor will ask for this. Pull it now and fix anything that looks bad.
• No control without evidence

  A control with no evidence is treated as non-existent. GuardDuty enabled but can't prove it? Same as GuardDuty off. Evidence collection is where most teams underestimate the time.

Only licensed CPA firms accredited by the AICPA can issue SOC 2 reports. Who you pick affects timeline and cost significantly.

• Shortlist 2–3 auditors who actually work with companies your size

  Big 4 firms charge $30K+ and treat your 10-person startup like a Fortune 500 audit. Startup-friendly firms that do this routinely: Prescient Security, Barr Advisory, Johanson Group, Sensiba, A-LIGN, Insight Assurance. Get quotes from multiple.
• Ask every auditor: "What does your readiness assessment look like?"

  A readiness assessment is a pre-audit checkup. Good auditors run it collaboratively. Bad ones use it as billable hours to find problems you should have caught yourself. Completing steps 1–4 of this checklist first is how you shorten it.
• Show up with your evidence already organized

  Teams that arrive with an organized evidence package move through the audit 2–3x faster. Your auditor is checking your homework. Come with it done.
• Fix every gap before the official audit starts

  The readiness assessment will find something. Fix those gaps before the audit period begins. Gaps found during the actual audit extend your timeline and raise costs.
• Budget for a penetration test

  Not required by SOC 2. But most enterprise buyers at Series A+ ask for it, and most auditors expect to see it. Budget $3–8K and schedule it before or during your audit window. Don't get caught without it when a deal is closing.

Most compliance guides skip this. Type I is not a comprehensive security certification. Knowing what it doesn't prove is as important as knowing what it does.

• The technical controls in this doc cover a lot. The governance layer doesn't have an API.

  CC6, CC7, CC8, and CC9 technical controls are highly automatable via AWS APIs. CC1–CC4 (org structure, risk processes, training records, HR controls) are manual. No scanner covers those. Budget time for them separately.
• Type I doesn't prove your controls worked over time

  That's Type II. If a customer asks "can you prove your access controls have been working for the last 12 months?" — that's a Type II question. Type I gets you in the door. Type II keeps you there.
• SOC 2 compliance does not mean you're secure

  SOC 2 measures process maturity, not security effectiveness. Companies with Type II certifications have been breached. The report tells customers you have a security program. Treat it as a floor.